Methods and apparatus for control using control devices that communicate via an ip network

ABSTRACT

The invention provides improved methods and apparatus for control using field and control devices that provide a virtual machine environment and that communicate via an IP network. By way of non-limiting example, such field device can be an “intelligent” transmitter or actuator that includes a low power processor, along with a random access memory, a read-only memory, FlashRAM, and a sensor interface. The processor can execute a real-time operating system, as well as a Java virtual machine (JVM). Java byte code executes in the JVM to configure the field device to perform typical process control functions, e.g., for proportional integral derivative (PID) control and signal conditioning. Control networks can include a plurality of such field and control devices interconnected by an IP network, such as an Ethernet.

This application is a continuation of U.S. patent application Ser. No.11/781,219, filed Jul. 20, 2007, entitled METHODS AND APPARATUS FORCONTROL USING CONTROL DEVICES THAT PROVIDE A VIRTUAL MACHINE ENVIRONMENTAND THAT COMMUNICATE VIA AN IP NETWORK, which is a divisional of U.S.patent application Ser. No. 11/354,586, filed Feb. 14, 2006, entitledMETHODS AND APPARATUS FOR CONTROL USING CONTROL DEVICES THAT PROVIDE AVIRTUAL MACHINE ENVIRONMENT AND THAT COMMUNICATE VIA AN IP NETWORK,which is a continuation of U.S. patent application Ser. No. 10/756,187,filed Jan. 13, 2004, entitled METHODS AND APPARATUS FOR CONTROL USINGCONTROL DEVICES THAT PROVIDE A VIRTUAL MACHINE ENVIRONMENT AND THATCOMMUNICATE VIA AN IP NETWORK (now issued as U.S. Pat. No. 7,020,532),which is a continuation of U.S. patent application Ser. No. 09/591,604,filed Jun. 9, 2000, entitled METHODS AND APPARATUS FOR CONTROL USINGCONTROL DEVICES THAT PROVIDE A VIRTUAL MACHINE ENVIRONMENT AND THATCOMMUNICATE VIA AN IP NETWORK (now issued as U.S. Pat. No. 6,788,980),which claims the priority of the following United States patentapplications: U.S. Patent Application Ser. No. 60/139,071, entitledOMNIBUS AND WEB CONTROL, filed Jun. 11, 1999; U.S. Patent ApplicationSer. No. 60/144,693, entitled OMNIBUS AND WEB CONTROL, filed Jul. 20,1999; U.S. Patent Application Ser. No. 60/149,276, entitled METHODS ANDAPPARATUS FOR PROCESS CONTROL (“AUTOARCHITECTURE”), filed Aug. 17, 1999;U.S. patent application Ser. No. 09/345,215, entitled PROCESS CONTROLSYSTEM AND METHOD WITH IMPROVED DISTRIBUTION, INSTALLATION, ANDVALIDATION OF COMPONENTS, filed Jun. 30, 1999 (now issued as U.S. Pat.No. 6,501,995). The teachings of all of the aforementioned applicationsand patents are hereby incorporated herein by reference.

BACKGROUND OF THE INVENTION

The invention pertains to control systems and, more particularly, tomethods and apparatus for networking, configuring and operating fielddevices, controllers, consoles and other control devices.

The terms “control” and “control systems” refer to the control of adevice or system by monitoring one or more of its characteristics. Thisis used to insure that output, processing, quality and/or efficiencyremain within desired parameters over the course of time. In manycontrol systems, digital data processing or other automated apparatusmonitor a device, process or system and automatically adjust itsoperational parameters. In other control systems, such apparatus monitorthe device, process or system and display alarms or other indicia of itscharacteristics, leaving responsibility for adjustment to the operator.

Control is used in a number of fields. Process control, for example, isemployed in the manufacturing sector for process, repetitive anddiscrete manufactures, though, it also has wide application in utilityand other service industries. Environmental control finds application inresidential, commercial, institutional and industrial settings, wheretemperature and other environmental factors must be properly maintained.Control is also used in articles of manufacture, from toasters toaircraft, to monitor and control device operation.

Modern day control systems typically include a combination of fielddevices, controllers, workstations and other more powerful digital dataprocessing apparatus, the functions of which may overlap or be combined.Field devices include temperature, flow and other sensors that measurecharacteristics of the subject device, process or system. They alsoinclude valves and other actuators that mechanically, electrically,magnetically, or otherwise effect the desired control.

Controllers generate settings for the control devices based onmeasurements from sensor type field devices. Controller operation istypically based on a “control algorithm” that maintains a controlledsystem at a desired level, or drives it to that level, by minimizingdifferences between the values measured by the sensors and, for example,a setpoint defined by the operator.

Workstations, control stations and the like are typically used toconfigure and monitor the process as a whole. They are often also usedto execute higher-levels of process control, e.g., coordinating groupsof controllers and responding to alarm conditions occurring within them.

In a food processing plant, for example, a workstation coordinatescontrollers that actuate conveyors, valves, and the like, to transportsoup stock and other ingredients to a processing vessel. The workstationalso configures and monitors the controllers that maintain the contentsof that vessel at a simmer or low boil. The latter operate, for example,by comparing measurements of vapor pressure in the processing vesselwith a desired setpoint. If the vessel pressure is too low, the controlalgorithm may call for incrementally opening the heating gas valves,thereby, driving the pressure and boiling activity upwards. As thepressure approaches the desired setpoint, the algorithm requiresincrementally leveling the valves to maintain the roil of the boil.

The field devices, controllers, workstations and other components thatmake up a process control system typically communicate overheterogeneous media. Field devices connect with controllers, forexample, over dedicated “fieldbuses” operating under proprietary orindustry-specific protocols. Examples of these are FoxCom™, Profibus,ControlNet, ModBus, DeviceNet, among others. The controllers themselvesmay be connected to one another, as well as to workstations, viabackplane or other proprietary high-speed dedicated buses, such asNodebus™. Communications among workstations and plant orenterprise-level processors may be via Ethernet networks or otherInternet Protocol (IP) networks.

Control device manufacturers, individually, and the control industry, asa whole, have pushed for some uniformity among otherwise competingcommunication standards. The Foundation Fieldbus, for example, is theresult of an industry-wide effort to define a uniform protocol forcommunications among processor-equipped (or “intelligent”) fielddevices. Efforts such as this have been limited to specific segments ofthe control hierarchy (e.g., bus communications among field devices) andare typically hampered by technological changes that all to soon renderthe standards obsolete.

Still less uniform are the command and operation of control devices.Though field devices may function at the direction of controllers andcontrollers, in turn, at the direction of workstations (or otherplant-level processors), proprietary mechanisms within the individualcomponents determine how they perform their respective functions. Eventhe commands for invoking those functions may be manufacturer- orproduct-specific. Thus, the commands necessary to drive actuators of onemanufacturer will differ from those of another. How the correspondingcommands are processed internally within the actuators differ still more(though, hopefully, the results achieved are the same). The specificprogramming codes used to effect a given control algorithm likewisediffers among competing makes, as do those of the higher-level controlprocessors.

Industry efforts toward harmonization of software for command andoperation of control devices have focused on editing languages thatdefine process control algorithms. This is distinct from the codes usedto effect those algorithms within control devices and, rather, concernssoftware “tools” available to users to specify the algorithms, e.g.,editors including IEC-1131 standard languages such as Field Blocks,Sequential Function Charts (SFC), Ladder Logic and Structured Text.

Less concerted are industry moves to extend monitoring and limitedconfiguration capabilities beyond in-plant consoles, e.g., to remoteworkstations. An example of this was the abortive Java for DistributedControl (JDC) effort, which proposed enabling in-plant workstations toserve web pages to remote Java bytecode-enabled client computers. Thelatter used the to web pages to monitor and set control parameters whichthe workstations, in turn, incorporated into their own control schemes.

An academic system along these same lines was suggested by the MercuryProject of the University of Southern California, proposing the use of aweb browser to enable remote users to control a robotic arm via a serverthat controlled the arm. A related company-specific effort included thatannounced by Tribe Computer Works that allegedly enabled users to managerouters and remote access servers over IP networks using web browsersoftware. See, “Tribe Defines Net Management Role For Web BrowserSoftware,” Network World, May 22, 1995, at p. 14.

Thus sets the stage for the present invention, an object of which is toprovide improved methods and apparatus for networking, configuring andoperating field devices, controllers, consoles and other controldevices. A related object is to provide such methods and apparatus forprocess control.

Further objects of the invention are to provide such methods andapparatus as reduce the confusion, complexity and costs attendant toprior art control systems.

Related objects of the invention are to provide such methods andapparatus as can be implemented with commercial off the shelf hardwareand software.

Still further objects of the invention are to provide such methods andapparatus as achieve confusion-, complexity- and cost-reduction withouthampering manufacturer creativity and without removing incentives todevelopment of product differentiators.

SUMMARY OF THE INVENTION

The foregoing are among the objects attained by invention whichprovides, in one aspect, an improved field device for a process or othercontrol system. The field device includes a virtual machine environmentfor executing Java byte code (or other such intermediate code) that, forexample, configures the device to execute a control algorithm.

By way of non-limiting example, the field device can be an “intelligent”transmitter or actuator that includes a low power processor, along witha random access memory, a read-only memory, FlashRAM, and a sensorinterface. The processor can execute a real-time operating system, aswell as a Java virtual machine (JVM). Java byte code executes in the JVMto configure the field device to perform typical process controlfunctions, e.g., for proportional integral derivative (PID) control andsignal conditioning.

Further aspects of the invention provide a field device, such as alow-power intelligent actuator, that incorporates an embedded webserver. This can be used to configure, monitor and/or maintain thedevice itself (as well as other elements of the control system) via abrowser attached directly to the device or coupled to it over thenetwork. To this end, the field device can incorporate a configurationeditor, e.g., operating on a processor within the field device, that anend-user executes via the browser and web server.

Such a configuration editor can, in related aspects of the invention, beenabled or disabled depending on the environment in which it is used andmore specifically, for example, the type of network in which it isincorporated. Thus, for example, the editor can be disabled when thefield device is incorporated in a process control network that includes,e.g., an applications development environment suitable for configurationof the field device. Conversely, it can be enabled when the field deviceis incorporated in a network that lacks such a capability.

Still further aspects of the invention provide a field device asdescribed above that includes an interface to an IP network, throughwhich the device communicates with other elements of the control system.The IP network can be, for example, an Ethernet network. Moreover, itcan be “powered,” carrying electrical power as well as packets,datagrams, and other control or data signals. The field device, inrelated aspects of the invention, draws operational power, e.g., for itsprocessor and other components, from such a network.

Yet further aspects of the invention provide a field device as describedabove that obtains configuration information and/or its network addressfrom such an IP network upon start-up. To this end, on power-up orcoupling to the network, the field device can supply an identifier(e.g., attained from a letterbug, assigned by a hub, or otherwise) to aDHCP or other server on the network. Once provided with an IP address,the field device can formally enter into the control network, e.g., byposting its characteristics to a network bulletin board, e.g., using anetwork enabler such as a Jini and/or JavaSpace server, or the like.Other network devices monitoring or notified via such a bulletin boardcan send configuration information to the field device or otherwise.

Still further aspects of the invention provide control devices, such asservers, control stations, operator consoles, personal computers,handheld computers, and the like, having attributes as described above.Such control devices can have other attributes, according to furtheraspects of the invention. Thus, by way of non-limiting example, they canprovide web servers that collect process data from one or more controldevices, generate source for operator displays, provide access to thecontrol system, and host an applications development environment.

Still other aspects of the invention provide process, environmental,industrial and other control systems that comprise field and controldevices as described above that are coupled via an IP network and,particularly, for example, by a powered IP network.

Additional aspects of the invention are directed to DHCP servers andnetwork enablers (optionally, including web servers) for use in controlsystems as described above. Related aspects provide such servers andenablers as are embodied in solid state technologies, e.g., with nomoving parts.

These and other aspects of the invention are evident in the attacheddrawings, and in the description and claims that follow.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the invention may be attained byreference to the drawings, in which:

FIG. 1 depicts a process control system 10 according to one practice ofthe invention;

FIGS. 2 and 3 depict more particular embodiments of a control system ofthe type shown in FIG. 1;

FIG. 4 depicts a native intelligent field device according to theinvention;

FIG. 5 depicts a native control device according to the invention; and

FIG. 6 depicts a native intelligent positioner implementation accordingto the invention.

DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENT

FIG. 1 depicts a process control system 10 according to the invention.The system includes networked control devices that monitor and control ahypothetical mixing process that utilizes mixing chamber 22, fluidinlets 24, 26, fluid outlet 28, paddle 30, cooler 32, and cooler inlet34. Though illustrated and described below for use in connection withprocess control, those skilled in the art will appreciate that apparatusand methods according to the invention can be used in connection anyindustrial, manufacturing, service, environmental or other process,device or system amenable to monitoring or control (hereinafter,collectively, “control”).

The networked control devices include actuators, such as the valvesdepicted as controlling inlets and outlets 24-28 and 34. A furtheractuator is shown controlling paddle 30. These and other actuatorsutilized by the control system are constructed and operated in theconventional manner, as modified in accord with the teachings hereof.The actuators operate under control of respective field devicecontrollers, labeled CTL, that are also constructed and operated in theconventional manner to provide initialization, signal conditioning andcommunications functions.

Rather than using separate controllers CTL, the actuators can be of theintelligent variety and can include integral microprocessors or otherdigital data processing apparatus for control, initialization, signalconditioning, communications and other control-related functions. Forsake of convenience, the label CTL is used regardless of whether thecontrol-related functionality is integral to the actuators (e.g., as inthe case of intelligent actuators) or otherwise.

Illustrated sensor 29 monitors a temperature, level or othercharacteristic of fluid in chamber 22. The sensor 29, as well as othersensing apparatus utilized by the system, are constructed and operatedin the conventional manner known in the art, as modified in accord withthe teachings hereof. They can be coupled to the control network via atransmitter or other interface device INT that, too, is constructed andoperated in the conventional manner, as modified by the teachingshereof. The interface devices facilitate initialization, signalconditioning and communications between the sensors and the controlsystem. As above, one or more sensors can be of the intelligent variety,incorporating integral microprocessors or other digital data processingcapabilities for initialization, signal conditioning, communications andother control-related functions. Here, too, the label INT is used inreference to the control-related functionality, regardless of whetherembodied in an intelligent transmitter or otherwise.

The networked control devices include one or more controllers 36 thatmonitor and control respective aspects of the hypothetical mixingprocess in the conventional manner, as modified in accord with theteachings hereof. The controllers can comprise mainframe computers,workstations, personal computers, special-purpose hardware or otherdigital data processing apparatus capable of performing conventionalmonitoring and control functions. Preferred controllers are constructedand operated in the manner of the CP control processors commerciallyavailable from the assignee hereof, as modified in accord with theteachings herein.

The control system 10 includes a variety of devices that serve as userinterfaces and that provide configuration and/or control functions, allin the conventional manner as modified in accord with the teachingshereof. Illustrated for these purposes are workstation 40, laptopcomputer 42 and handheld computer 44. These devices can provideconfiguration and control functions directly, as in the case ofworkstation 40, or in cooperation with server devices, e.g., as in thecase of handheld computer 44 and server 46. Apparatus 40-44 can couplewith the control network directly, e.g., via bus or network connection,or indirectly, e.g., via satellite, wireless connection or modemconnection.

The control devices 36-46, CTL and INT, collectively, referred to as“native” devices, are coupled for communications via a medium thatpermits at least selected ones of the devices to communicate with oneanother. To this end, in the illustrated embodiment those devices arecoupled via one or more networks 48 that are, preferably, IP-based suchas, by way non-limiting example, Ethernets. The network(s) can include,as indicated by the multiple segments shown in the drawing, multiplesegments such as various wide and local area networks. They may alsoinclude high and/or low bandwidth components, such as phone lines, andlow and/or high latency components, such as geosynchronous satellitesnetworks.

FIG. 2 depicts a more particular embodiment of a control system 50 ofthe type shown in FIG. 1. The system includes an enterprise server 52, afirst thin client 54, plant server 56, a second thin client 58, acontroller 60, a Java-enabled field device 62, and one or more fielddevices 64, coupled to one another, e.g., in the manner illustrated, byone or more networks 66, 68.

Native enterprise server 52 (corresponding, by way of non-limitingexample, to server 46) comprises a mainframe computer or engineeringworkstation that executes enterprise-level applications such as, bynon-limiting example, those for financial, asset planning andprocurement, distribution and/or human resources. In addition, itsupports web serving, as well as optional object, relational and otherdatabase management systems. Server 52 executes Windows NT, Solaris oranother conventional commercial or proprietary operating system. It isalso equipped with a Java Virtual Machine (JVM), e.g., capable ofexecuting Java virtual machine instructions (bytecodes), of performingremote method invocation (RMI), and of supporting Jini networking. Theenterprise server 12 can be coupled to further networks, e.g., to theInternet, as shown, in any manner known in the art.

Native thin client 54 (corresponding, for example, to handheld computer44) provides similar functionality as server 52, though its actualprocessing activity is limited to user input and output. Applicationprocessing, such as financial, asset planning and procurement,distribution and/or human resources, are performed on behalf of client54 by a server, such as server 52. The operating system and JVMfunctions may be embedded in the conventional manner of a thin client.The thin client 54 is coupled to the enterprise server 52 over abusiness information network 66 (corresponding, for example, to network48), typically, an Ethernet or other IP network, configured in a LAN,WAN or the like.

Native plant server 56 (corresponding, by way of non-limiting example toworkstation 40) comprises a plant control console or engineeringworkstation modified in accord with the teachings hereof, executingplant-level control applications including system, process, engineering,plant information, configuration, lab quality, maintenance, resource anddocumentation applications of the type known in the art. Like enterpriseserver 52, plant server 56 can execute Windows NT, Solaris or otherconventional operating systems. It is also preferably equipped toexecute a Java Virtual Machine as described above. Plant server 56 iscoupled to the enterprise server 52 and thin client 54 over the businessinformation network 66.

Native thin client 58 provides similar functionality as server 56though, again, relies on that (or another) server to perform mostprocessing activity. As above, the operating system and JVM functionsmay be embedded in the conventional manner of a thin client. The thinclient 58 is coupled to the plant server 56 over a control network 68(corresponding, for example, to network 48), e.g., an Ethernet.

Native controller 60 (corresponding, for example, to controller 36)executes control algorithms to control associated non-native fielddevices 64, e.g., via any variety of commercial and/or proprietary fieldbus 70 hardware and protocols. Where processing resources are limited,the controller 60 utilizes a embedded operating system that supports webserving and the JVM. The controller 60 is coupled to the plant sever 66and to the thin client 58 via control network 68.

Native field device 62 is a sensor, actuator or other field device. Theillustrated device is of the intelligent variety, including processor(not shown) and operating system. It can be of the type commerciallyavailable in the marketplace, as modified in accord with the teachingshereof. The illustrated device supports web serving and JVM, asdescribed above. The device 62 provides information collection andcontrol functions, as illustrated.

FIG. 3 depicts another a more particular embodiment of a control system50 of the type shown in FIG. 1.

Referring to FIG. 1, the illustrated control system 10, 50 uses webbrowsers, Java, Jini, JavaSpaces, TCP/IP and other technologies normallyassociated with the Internet and the world wide web to create aself-defining control network that minimizes complexity whileemphasizing the portability and re-usability of the user's application.These technologies are advantageously employed to eliminate proprietaryhardware and software to preserve the user's investments; eliminatenetwork configuration and system management through self-configuringnetworks; increase the user's choice of algorithm suppliers byimplementing control in Java; preserve the user's applications throughhardware and system software changes through the use of Java and WebBrowsers for process displays; minimize the wiring costs; reducemaintenance by making intelligent field devices a practical reality.

In addition to web technologies, the illustrated control system 10 usesan object location service, a commercial messaging service, and standardnetworking equipment, such as hubs, routers, network interface cards,where applicable. It also relies on common standards, where applicable,such as 802.3, Internet RFCs, the IEEE 1451 sensor standards. The system10 supports a heterogeneous computing environment and utilizes industrystandards (e.g., Microsoft standards) to provide communications betweenthe native control components to the business and desktop environments.

1 Device Hardware 1.1 Platform-Defining Control Devices

In the illustrated embodiment, native control devices such ascontrollers 36, 60, workstation 40, servers 46, 52, 56 providing aplatform for the control system typically include a central processingunit (CPU), memory (RAM), network support hardware, access to permanentstorage, an operating system, and a Java Virtual Machine (JVM) includingthe TCP/IP suite. In addition, the devices include web server software,e.g., software of the type that serves graphical “web” pages in responseto requests by other devices. Configurator software can be provided, aswell, permitting each device to configure the control system or selectedportions of it. Those skilled in the art will appreciate that not all ofthese components need be included in all native control devices, e.g.,some commercially available JVMs can serve as an OS themselves.

Process control object (PCO) software provided on the platform-definingcontrol devices comprise a collection of data and methods implemented inJava and executed on the native control devices' JVMs to perform typicalprocess control functions, by way of non-limiting example, signalconditioning and PID control. Likewise, station management object (SMO)software on the devices comprise data and methods that allow the deviceto report its health, performance, and other status information in auniform manner. The SMO software can implement SNMP or the equivalentJava functionality.

Software is also provided on the platform-defining controls devices formessaging services for data transfer and alarm/event notification, aswell as software comprising system management pages. Each control devicemay include additional software, of course, depending on itsfunctionality.

1.2 Field Devices

Native intelligent field devices typically include a low power CPU,e.g., a NetARM or Java Chip; a real-time OS like VxWorks, QNX, PSOS;RAM; FlashRAM to serve as permanent storage; ROM/EEPROM to serve as thehome for the OS and other permanent software; an Ethernet interface;power from the Ethernet interface (in the event a powered Ethernetnetwork or hub is used) or otherwise; a sensor interface, e.g., IEEE1451.1 and 1451.2; JVM; a web server, and a device specific configuratorservlet. A field device so constructed can be configured and monitoredvia a lightweight web browser, e.g., handheld computer 44, coupled tothe device over the network 48.

The field devices can include serial interfaces to allow the attachmentof these devices to HART, FoxComm, Profibus and other networks operatingunder a protocol different from that of network 48. Combined withappropriate software, these devices provide the user with a singletransmitter suitable for use on any field network.

One configuration of a native intelligent field device including theelements described above these elements is shown in FIG. 5. Thoseskilled in the art will appreciate that other configurations can berealized, as well, in accord with the teachings hereof.

1.2.1 Stoic Sensors

The control system 10 can include one or more stoic sensors, notillustrated, that constitute minimal sensing elements. Typically, theseare simply silicon chips that are packaged to allow them to sense theprocess environment and that have only enough electronics to relaymeasurements to a pair of wires that carry the raw signal to anotherdevice for processing. Some stoic sensors generate a signal withoutexternal power; others require some excitation. In a preferredembodiment, native devices 36-46, CTL and INT according to the inventionsupport the attachment of many stoic sensors.

1.2.2 I/O 1.2.2.1 Overview

Some I/O devices, e.g., thermocouples, RTDs and analog transmitters, maynot use a transmitter compatible with the network 48 but, rather, sendraw sensor output to a multiplexor for processing. To accommodate thesedevices, the system 10 includes two types of intelligent I/O cards:network I/O cards supporting IP and an API, and native I/O cards thatsupport the protocol of network 48 (i.e., the “native” protocol)directly.

Network I/O cards are coupled directly to network 48. Native controldevices are IP enabled and support the proprietary API of the cards,thereby, permitting reading and writing of their I/O registers. Thecards' respective APIs support retrieval of data in several formats (rawcounts, linearized counts, engineering units, etc.), as well as theassignment of simple configuration information to those registers, ifthe device supports such functions. To this end, the native devicesutilize I/O classes that corresponding to the native I/O protocols.Redundant I/O devices can be physically interfaced transparently througha single I/O card or through multiple independent network I/O cards.Logically, PCOs support at least the use of multiple independent cards.Alternative I/O features may be used in addition. Native I/O cards aresubstantially similar to native-enabled transmitters, except forpackaging and scale. These I/O cards may be considered as smallmulti-loop controllers or multiplexors.

1.2.2.2 Foreign Device Integration

Networked I/O cards are utilized with devices that cannot otherwisedirectly interface with the network 48. The cards, in this case, providean interface that permits at least reading and writing of relevantdevice values, which can be stored internally to the card and accessedvia its API. Foreign devices that are control systems in its own righttypically maintain objects or other data structures representing processvalues and associated data. A preferred interface to these “devices” arethrough objects that wrap the foreign function blocks with the servicesexpected of native devices, e.g., detail displays and configurators,which are accessed in exactly the same manner as native ones of thosesame services. For example, a name service is be able to locate foreignblocks and the native API of system 10 permits querying those blocks forvalues.

1.3 Native Controllers

In a preferred embodiment, all native devices may be used ascontrollers, though, dedicated I/O-less native controllers, such ascontrollers 36 and 60, are typically required for unit-wide operations.Thus, for example, control can also be provided by personal computers,workstations and servers of the type shown as elements 40, 42, 46, inFIG. 1. Native controllers, e.g., 36, 60 are of the same general designas native boards used in the transmitters and actuators. However, theysupport a faster CPU clock cycle and more memory (volatile andnon-volatile) than their smaller siblings. High performance nativecontrollers have a still more powerful CPU, more RAM, and maybe aremovable FlashRAM card for bulk storage and backup. Like the nativetransmitters and actuators, these native controllers can receive powerfrom a powered Ethernet connection or otherwise. Native controllers canbe used in redundant and non-redundant configurations. Since the I/O isindependent of the native controller, redundancy can be implemented in anumber of manners, e.g., hardware fault-tolerance or transaction basedsynchronization between stations with clustering.

1.4 Native Compliant Workstations

Native workstations, e.g., such as element 40, can be constitute webbrowser-enabled devices that communicate with web servers, such aselement 46, that actually collect the process data from other nativedevices. In addition, the workstations can consist of a flat paneldisplay, OS and web browser in ROM (or on a memory card), web page(process graphic) database/cache, connections for optional annunciatorkeyboards, option for wireless Ethernet, and, optional, batteryoperation. Data supporting the operator interface comes from nativedevices directly.

1.5 Native Web Server

If a generic web browser-enabled device is the operator's console, anative web server, such as servers 46, 52, 56 sources the operatordisplays. This can be implemented with redundancy using technologiesNT's clustering capabilities, or the like. Additionally, a native webserver provides access to a illustrated control system 10 to users notphysically attached to the illustrated control system 10, e.g., asillustrated with respect to elements 44 and 46 of FIG. 1. In this mode,it centralizes data requests to maximize efficient use of communicationresources.

1.6 Native Enablers

1.6.1 The illustrated control system 10 includes native enablers 49,such as Jini and JavaSpaces devices and Solid-State DHCP servers. Theseenablers, which are optionally redundant, are preferably fully solidstate with persistent memories. They do not use batteries for theirpersistent memory, though they may well plug into a wall outlet forpower in non-industrial environments. The Jini and JavaSpaces serve ascommunity “bulletin boards.” These are used to notify system monitorsthat native devices have been added to or removed from the system. Thesystem monitors respond to such notices by triggering appropriateactions.

The illustrated control system 10 assumes that each native device isable to acquire an IP address when it comes on-line. To minimizeconfiguration, a DHCP server, illustrated for example by element 49, isrequired to furnish these addresses. To ensure maximum availability ofthis critical server, it is preferably a solid-state device and,optionally, includes a redundant partner DHCP Server. A particularnative DHCP server provides addresses for a portion of the network 48.It obtains its configuration by notifying the system 10 that it has comeon line. Those skilled in the art will, of course, appreciate that IPaddresses can be selected by mechanisms other than DHCP servers.

1.6.2 Native Internetwork Server

An internetwork server 47 is used to link separate control systemsnetworks 48. It provides a platform for inter-network communications,controlled access to data, name conflict resolution, and other servicesneed to efficiently, securely, and transparently accomplish theconnection of one or more illustrated control systems to another.

2 SubSystems 2.1 Software Downloads

The illustrated system permits the electronic downloading of softwareand/or licenses for execution on the native devices. This includesnative software objects, updates and/or licenses for same. To ensureproper operation of the process facility even in the event ofinsufficient licenses, downloaded software registers with the systemmonitor and declares whether or not it is licensed. In the case ofinsufficient licensing, the system monitor's notifies the customerappropriately.

In instances where appropriate native software modules andauthorizations are in place, the system 10 can access a download site,e.g., an Internet e-commerce site, and determines if updates areavailable. If so, it notifies the user and invites him/her to requestdownloading of the upgrade. Such an e-commerce or other web site canalso provide configuration tools that allow the user to design,implement, and test a new PCO block. This allows the user to accesscomplex and/or rapidly improving software tools without having tomaintain them locally. For this purpose, the use is charged, e.g., amodest access fee.

2.2 Security

The system 10 includes a native security system to control access tomanaged objects based on the type of access, e.g., (i) extra-network,i.e., users who are accessing the illustrated control system 10 from anon-native station; (ii) inter-network, i.e., users who are operatingfrom a native workstation on a different physical native network; and(iii) intra-network, i.e., users who are operating from a nativeworkstation within the particular native network.

Secured extra-system access is provided through a native secure webserver, e.g., server 46, that permits dial-up, network, and other remoteaccess and that supplies and defines the permitted extra-network access,including the API available to applications hosted outside the networkor on the server. See, for example, elements 44 and 46 of FIG. 1. Accessis controlled by user name, by user location (IP address or workstationname depending on the network), and by the type of the targeted object.

Inter-system access is provided by a gateway device, such as server 47,that permits the secure transfer of data. This device negotiates secureaccess, deals with name conflicts between systems, and provides supportfor various physical media A pair of such devices are provided toaccount for situations where the source is local to the sink. In apreferred system, the server 47 or other gateway encrypts the data sothat others cannot read it. Likewise, it authenticates message sourcesto verify that they are coming from a matching device. A preferredgateway minimizes the number of packet transfers so as to minimizedelays over slow or high latency links.

Secured intra-system access is controlled based on the user and theworkstation, leveraging the Java security model and other securitymodels to the extent possible. The native security system authenticatesusers, e.g., regardless of whether they are attempting access fromoperator's console or via an application program.

The native security system manages access to objects, including PCOattributes (i.e., variables and/or parameters of PCOs), system monitors,and native messages. It allows applications to add objects to the listof managed objects. Read and write access is preferably controlledseparately, i.e., as if a single PCO attribute was two separate objects.

The security model is based on a lock and key approach. Each PCOattribute, for example, is assigned to one of a large number of locks.The user is given different keys for read and write access to objectattributes. This key may be modified according to the type of nativeworkstation used for access. The key is passed to the object attributewhen the object attribute is accessed. If the access is a connection, itneed be passed only once. The object attribute compares the key to itslock and allow or deny access as appropriate.

A software tool is supplied with the applications developmentenvironment (ADE) or configurator that allows identification of users;access points allowed by the user; object attribute groups accessible tothe user; and access type (read or write) to the object types. Theobject attribute groups define collections of object attributes viasimilar security access guidelines, e.g., alarm limits might be in onegroup and tuning parameters might be in another. The security model isembedded in the APIs providing access to the secured objects. Thisassures that that access is granted only after the native securitysystem has performed the necessary verifications.

2.3 Maintenance and Support

The illustrated control system 10 supports the on-line upgrade of allapplication software from remote and local workstations. Applicationsoftware, for purposes of this discussion, includes the system monitor,PCOs, and other Java-based code. Native diagnostic and maintenance toolswork over user-supplied or other IP-based networks, providing that theyallow services such as the world wide web to operate over them toexternal sites. For networks that do not permit this, the illustratedcontrol system 10 provides modules that support direct connections to anative support center via dialup analog phone lines, and dialup highspeed lines, e.g., ISDN and ADSL. Native maintenance, including softwareupdates, operate over these connections; hence, it is not necessary fora person to be physically present to update system or applicationsoftware.

The illustrated control system IO includes diagnostics to track problemsfrom the hardware upwards. Maintenance staff can run in paralleldiagnostic versions of the software. Such software running in open loopor switched into operation as necessary is believed particularlyadvantageous for support purposes.

2.4 Configuration

An application development environment (ADE) coordinates configurationin the illustrated control system 10, e.g., except for devices (such ascertain transmitters and positioners) where use of an ADE is notadvantageous and for which internal configuration is preferred.Characteristics of the ADE are its use in configuring/building controlapplications including control schemes, displays, historians, etc.;support of multiple simultaneous users; support of remote, concurrentdevelopment; support of change tracking and change management includingtask based activity traces, summary reports, change annotation, approvalcycles, and user identification; a human interface component that runsin any web browser coupled to the system; a server component that runson any user-supplied system; permanent storage comprising a commercialdatabase for which a JDBC implementation is available; allowing thedefinition of configuration object templates; allowing the instantiationof configuration object templates into configuration objects; allowingthe user to add and remove editors for configuration object componentsin real-time; limiting the user's access to configuration capabilitiesin the various pieces of equipment; and supporting applicationdistribution along with verification of download permissions.

With respect to the support of multiple simultaneous users, systemeditors provide object-based “check-out” and “check-in.” No other useris allowed to edit a checked-out object or any of the objects that itcontains. As an alternative, editors support the concept of task-basedconfiguration activities and the related “check-out” and “check-in”facilities required to make it work. When an object is checked out, itis assigned to a task. Objects are not checked back in, tasks are. Abuild manager has the responsibility of integrating the tasks.

The native ADE delivers lower engineering and maintenance costs throughthe unification of application development, preservation of applicationexpertise, reduction of application development effort, and thedeployment of developed applications. Is it based on industry standards(e.g., IEC 1131 and IEC 1499) to preserve the user's investment intraining and applications. It also produces appropriately formatted Javaclass for execution in native devices. Since the native ADE producesoutput that can be read and loaded into a JVM and since the nativecontrol devices include JVM, one control configurator can configure allnative devices.

In a preferred embodiment, the ADE imports configurations from legacysystems; supports the use of third-party control algorithms; andsupports both bulk building of control configurations and on-linechanges with validation.

Configuration is not limited to implementation on a web browser, thoughthis can be advantageous since it allows configuration from many typesof device without installation of special software, i.e., it provides athin-client configuration mechanism. For device configuration, there aretwo cases: a device used in illustrated control system 10 and a deviceused outside illustrated control system 10. For devices used outsideillustrated control system 10, the configurator is placed in the deviceso that it can be configured even without the native ADE. This on-boardconfigurator allows the device to be configured for use with Profibus,Foundation Fieldbus, on 4-20 ma wires, and other industry-standard orproprietary networks. For devices used in the native environment, (i) acopy of the configurator is available from a native web server foroff-line configuration and download, and (ii) the on-board configuratoris disabled to prevent changes in the configuration except through theADE.

2.5 Human Interface

The illustrated system's primary human interface (HI) device is a webbrowser. The current range of devices executing these spans cellularphones to mainframe computers. The native HI is multilingual, i.e., itsupports the presentation of information in a default language and oneor more secondary languages simultaneously. All standard nativeapplications support text substitution based on the currently selectedlanguage. Error messages are likewise in the currently selectedlanguage.

2.6 Process Control

Process Control is implemented using process control objects (PCOs)running in an execution environment consisting of a JVM and anyassociated applications required to load and execute the specifiedcontrol strategies. Control strategies are specified in terms of PCOcomposites. PCOs are Java classes designed to be modular and easilyupgraded even during operation. The native PCO configurator, from a highlevel view, creates instances of these classes, connects them asnecessary, and installs them in particular devices.

Process control objects consist of two user-available types: blocks andcomposites. PCO blocks are, from the user's point of view, similar toconventional function blocks. Likewise, composites are similar toconventional collections of function blocks. Distinguishing externalfeatures of PCOs include the fact that changes involve theaddition/deletion of PCOs and cause new versions to be loaded into thetargeted native device. The new version runs in parallel with the oldversion until the engineer decides that it is operating properly and“swaps” the control from old to new.

Composite PCOs may span stations transparently. PCOs are bound tostations very late in the configuration process and may be migrated fromone station to another at any time. Further, PCOs from different sourcesmay operate in the same device if the configurator supports the use ofmultiple PCO libraries.

A native PCO configurator supports multiple libraries of PCOs frommultiple vendors; permits the creation of composite PCOs from otherPCOs; permits the use of composite PCOs as templates, with a compositePCO definition specifying which fields is altered in a template; permitsthe assignment of PCOs to physical devices; provides IEC 1131/1499influenced view of the configuration process, i.e., support for LogicDiagrams, Structured Text, Sequential Function Charts, Function Blocks,and PCOs, while producing Java byte code as its output.

The creation of composites includes the raising of internal (deeplyburied) names to the top level of the composite PCO. For example, acascaded Temperature/Flow loop might have the temperature and flowmeasurements referenced as TC_CASCADE:PRIMARYFLOW andTC_CASCADE:SECONDARYFLOW or as the longer fully qualified name. Theconfigurator works both off-line in a bulk creation mode and on-line inan individual correction mode.

2.7 Communications: Object Location, Message Transfer, and Data Transfer

The concepts of object location and data/message transfer are closelybound. A process control system imposes significant quality of servicerequirements on any services used to locate objects of interest and toacquire values from or make changes to those objects. The illustratedsystem includes an object location and data transfer service thatprovides a communication model definition, security, object locationservices, network types requiring support, quality of service, APIs(Java and non-Java), maintenance and upgrade strategy, andinteroperability with existing control systems. In addition, thecommunications system addresses the particular needs of process datatransfer.

2.8 Critical Applications 2.8.1 Time Synchronization

The illustrated control system 10 supports time synchronization to themillisecond in each station on the network 46. Where equipmentconfiguration renders this impossible, time synchronization to 50 ms isprovided.

2.8.2 Alarm and Message Management

The illustrated control system 10 provides a facility that centralizesviewing, recording, organizing, and categorizing the messages generatedby the system monitor, the operator action journals, the PCOs, and othersystems that record textual information. This application is the basisfor alarm management strategies including inferential alarming and alarmprediction. However, the message management facility is not in and ofitself an alarm historian. Rather, it relies on a native historian toprovide the long-term storage of this information.

2.8.3 Historian

The native historian provides the fundamental data collection,reduction, and archival services. The data collected includes processvalues and messages from various applications within the illustratedcontrol system 10. In addition, it provides historical data in supportof several other common applications—typically known as plantinformation management system (PIMS) programs and trend window support.The historian is capable of exporting its data to user-selecteddatabases.

2.8.4 Plant Information Management System

These applications include a simple and easy to report writing facility,a calculation facility that can use historical and real-time data tocompute new values, and a desktop visualization system that uses thehistorians data instead of real-time data. The desktop visualizationsystem uses the native graphics capabilities to connect the graphics tothe historian and to allow the operator to “move” the entire graphicbackwards and forwards through the historical data. The valuescalculated by the calculation facility are stored in PCOs that representthe data and generate appropriate alarms. The report writing facilitysupports shift reports with calendar adjustments as a simple to usefeature. In addition, it facilitates the definition of ad-hoc reportsusing a page layout metaphor.

3 Interoperablity

Interoperability of the illustrated control system IO with legacyprocess control systems can be facilitated by adding a networked I/Omodule to the I/O chain of existing I/O cards, adding a native deviceintegrator to talk to other networks of devices, or utilizing a nativeAPI for Microsoft- and Solaris-based applications.

4 Operating the Control System 4.1 System Startup and Management 4.1.1Device Identification

Each native device is assigned a name that is used to identify thedevice and obtain any configuration information that it needs.Embodiments of the invention use alternate approaches to identifying adevice, including using a hub that is configured by the user to assign aname to each of its ports, e.g., using letterbug or softwareconfiguration; installing a letterbug, e.g., on the workshop bench,which tells the device its name; using a PC or handheld computer, e.g.,on the workshop bench, to give the device its name; or using softletterbugs.

4.1.2 Address Acquisition

After a native device has its name, it acquires its IP address from itsenvironment. The illustrated embodiment uses DHCP for this purpose.Preferably, the DHCP server is a native device, such as enabler 49,though other DHCP servers can be used, as well.

4.1.3 Registration of the Device

Once the device knows its address, it registers its characteristics on anative bulletin board, which can be colocated with the DHCP server,e.g., in an enabler 49. Typically, many software services in the system10 register with the bulletin board for notification of additions ofnative devices. Upon registration of a device, these services arenotified and enter into relationships, if any, with the new device. Atypical situation would involve notifying a system monitor process thata native device is active. That process then updates its web page withinformation about this device. In a preferred embodiment that utilizes ahierarchical network, each bulletin board is covers a given “territory”or region of the network.

4.1.4 Configuration Acquisition

If a device is unconfigured, it marks the “Configured” attribute on itsbulletin board entry as “False”. Any system monitor receiving devicenotifications to this effect generates an alert. Once a device has itsname, it is able to communicate with any networked supply ofnon-volatile storage. This is particularly useful in the case of deviceswith limited in device non-volatile storage, whom a system configurationutility notifies of the location of configuration information. Devicesthat can retain all of their configuration information can start upusing that configuration. Actions taken during start-up, e.g., takingPID algorithms out of hold, are configurable.

4.1.5 System Monitors

A system monitor monitors the health of system components (hardware andsoftware), monitors the health and operation of user applications,provides configuration information to devices that request it, andmonitors the licensing of software and upgrades for purposes of alertingthe appropriate groups. The system monitor supports standard SNMP agentsand any native specific system management protocols.

The predominant source of information used by the system monitors arethe bulletin boards which, as noted above, are used by the nativedevices to record their current state of operation. As devices are addedand removed from the bulletin boards, the system monitor displays thatinformation. The information posted on the bulletin boards includesdiagnostic information. A system monitor not only displays thisinformation but also allows the user to access and operate any embeddeddiagnostic displays and operations.

4.2 Device Configuration and Management 4.2.1 Device Startup

Initial start-up of a native device involves the following steps:

-   -   1) Install the device on the network 48 and turn on the power as        required by the device.    -   2) The device obtains an IP address from a DHCP server 49 on the        network 48.    -   3) The device registers with the native name service.    -   4) The device waits for a configuration.    -   5) The device is now ready for configuration.

Restart of a native device is effected by the steps of

-   -   1) Install the device on the network 48 and turn on the power.    -   2) The device obtains an IP address from a DHCP server on the        network.    -   3) The device registers with the bulletin board.    -   4) The device begins operation according the configuration        stored in its non-volatile RAM. This RAM may be a network        resource that it must recover. If that resource is unavailable,        the device is essentially unconfigured and the above procedure        is followed.    -   5) The device is now ready for configuration and operation.

4.2.2 On-Line Configuration

The steps involved in on-line native device configuration are:

-   -   1) The engineer starts a web browser on workstation 40, handheld        computer 44 (wireless or otherwise), a PC, a native workstation,        etc.    -   2) The default home page on the browser is cached and contains        an applet that locates the native bulletin board and raises the        initial web page that lists the services available from that        workstation.    -   3) The engineer selects the ADE and a native device of interest.

If the device is on a native network 48, the native configurator (ADE)is used to make the changes. In this case, the web browser is pointed atthe web server that hosts the ADE. This approach eliminates conflictsbetween field change and database changes. The configuration ofnon-native devices is provided by a service that encapsulates the nativecommands and passes them through a native device to the actual foreigndevice.

The steps in PCO configuration are

-   -   1) As in the off-line mode, the engineer accesses the ADE and        makes necessary changes.    -   2) Once the changes are complete, the engineer tells the new        objects to begin execution in “open loop” mode, i.e., their        outputs are not allowed to go to the field or to any other        display station other than the one used to configure them. (For        examples, their names are not registered with the native name        service.)    -   3) In the open loop mode, the engineer can “Verify and Validate”        his new control scheme by viewing the detail displays for the        new and the old objects “in parallel”. The set of available        detail displays may include special displays for evaluation of        parallel composites.    -   4) Once the configuration is complete, the device records its        new configuration in its local non-volatile RAM. Optionally, it        updates a remote configuration database or just set a “changed        configuration” status indicator much like conventional        intelligent transmitters.

5 Native Software Subsystems 5.1 Security 5.1.1 Object Access 5.1.1.1Locks and Keys

As noted above, the proposed security mechanism is a lock and key. Inthis model, the attributes of an object that are available to bemanipulated are assigned a lock number. An application registers withthe security system at start-up to obtain a key. The value of the keydepends on the effective user id (name) and the station on which theapplication is running. The key is never visible to the user, so he/shecannot alter it. This key is available to any library that uses thesecurity system to ensure proper access.

5.1.1.2 Security Database

A security database contains a list of users. For each user it allowsthe specification of a master key, i.e., a bit array with a bit set foreach lock the user is allowed to unlock. There is one master key foreach object type supported by the security system. By default, thesecurity system supports the creation of master keys for the systemmonitor, process data (PCO attributes), and native messages (events).The database also allows modifications to the master key for a userbased on the station used to perform an operation. These exceptions canbe expressed as IP addresses, station names, or by the type of accessbeing used (e.g., extra-system, inter-system, or intra-system).

5.1.1.3 Operation

The security system supports caching the security system database onspecific servers to improve redundant operation and to speed keyqueries. This is generally not a significant issue since the query isdone once per application. Each time an operation is attempted or, insome circumstances, once per connection, the key is passed to the targetobject along with any other information required by the object toachieve the user's request. It is the responsibility of the object tomatch a bit in the key with the lock on the attribute or method beingaltered. If there is a match, the operation proceeds. If the matchfails, the operation is aborted and the calling application is notifiedof the failure. If the lock is zero, the operation is allowed tocontinue.

5.1.1.4 Use

According to a preferred practice, the illustrated control system 10supports at least 256 individual locks. This allows the applicationengineer to define 255 groups of objects for each type of object beingaccessed.

5.1.1.5 Impact on PCOs and Other System Components

The value record of a PCO attribute includes two keys: one for readaccess and one for write access. A default value for the key can beinherited according to rules concerning the use of the attribute, e.g.,all alarm attributes have an assigned group by default. A system monitorinterface implements the same mechanism.

5.2 Maintenance and Support 5.3 Configuration

A configuration object (CO) is a collection of objects plus the editorused to manipulate them. A Configuration Object Template (COT) is a COthat has not been instantiated. The application development environment(ADE) is the environment for configuration object editors. It shows theuser the existing COs in the CO being edited and a list of availabletemplates. It provides the mechanism for adding objects to a CO byinstantiating a COT and for removing COs. A Configuration ObjectComponent (COC) is any of the objects found in a Configuration Object.Typical components are: PCOs, Process Graphics, Reports, HistorianConfiguration Objects, etc. The ADE has two components: the humaninterface and the server. Several human interfaces can access the sameserver at any time.

When a Native device is placed on-line, its internal configurationservices are disabled. All configuration instructions come from theapplication development environment. Where on-line configuration ispermitted, the system monitor or other system component flags anyconfiguration mismatches.

Invoking the ADE is tantamount to starting the editor of a particulartop-level CO. The ADE presents all of the available COs within theselected CO and all of the available COTs. The ADE provides a mechanismfor manipulating those objects and for adding new objects byinstantiating COTs. Since the objects within the ADE are alsoConfiguration Objects, i.e., they are themselves collections of objectswith associated editors, configuration involves selecting an object,invoking its editor, and making changes. Each editor knows how to storeits object's data in the persistent storage.

The ADE preferably includes a system editor, a control editor, a graphiceditor, a message manager editor, a historian editor. All editorssupport the use and creation of templates by the user. The also supportthe assignment of their objects to particular stations in the nativenetwork. Not all objects require assignment, but the editors areresponsible for it.

5.3.1 System Editor

The system editor allows the user to configure a logical arrangement ofnative device objects. The only devices it configures are those that arenative-enabled. If a device, such as Networked I/O, does not supportNative, this editor is not interested in it. The following table liststhose devices, what they do, and what needs to be configured.

System Editor Device Type Description Configured Attributes DHCP/BulletThese devices allocate IP Name and association in Board addresses tostations and act as with a Web Server Server the bulletin board for thestations that ask for addresses. They are not configured to know whatdevices might be attached. Native These devices act as PCO Name andassociation Controllers platforms. with a DHCP/bulletin board Server(which may be a Web Server) Native The devices that supply the Name andassociation Workstations human interface to the process. with aDHCP/bulletin board Server (which may be a Web Server) Native Web Thisdevices host Native Name Servers Applications and graphics. NativeWorkstations may also be Web Servers.

As with the other editors, the system editor is object oriented andtemplate driven. The user is allowed to select an object type from apalette and attach it to the appropriate stations. Individual DeviceEditors are provided for each of the device types.

5.3.1.1 DHCP/Bulletin Board Editor

If the device is assigned to another DHCP/bulletin board device or a webserver, the editor allows the user to specify the number of IP addressesthat this device needs to be able to supply below it. In this case, whenthe device starts up, it gets its own IP address and IP address rangefrom the Web Server or DHCP/bulletin board device to which it isassigned. If it is not assigned to such a device, the editor allows arange of IP addresses to be assigned to it. It is assumed that thedevice gets its own IP address from another, non-Native DHCP Server.

5.3.1.2 Native PCO platforms

Each device type on the network is provided a specific editor to controlits specific configuration. Typical devices are: transmitters,actuators, controllers, etc. These editors are available for off-lineconfiguration. In this case, the system monitor downloads any approvedconfigurations at the next start-up. The editors may also be availableon-board the device (e.g., for fixed function devices such as singlestation controllers), which allows direct configuration through a webbrowser. The on-board facility is automatically disabled once the deviceis placed on a native network. This ensures database consistency whileallowing the use of the device on non-native networks. In theillustrated embodiment, device specific configurators are provide in ADEadd-in and on-board, preferably, with the same code would be availableand used for both.

5.3.1.3 Native Workstations

The configuration of this device includes user name(s) allowed; readonly operation; full fledged operator; and so forth.

5.3.1.4 Native Server

The configuration of this station is a range of addresses if it isacting as a DHCP server.

5.3.2 The Control Editor

The Control Editor implements PCOs plus four of the IEC 1131-3 languages(LD, ST, SFC, and FB). Any control schemes built in those languages aretranslated into a Java file, compiled, and downloaded. The IEC 1131-3concept of configurations, resources, programs, and tasks are translatedinto the native environment that consists of set of native platforms. Inaddition, the Control Editor supports defining of control schemes usingPCOs in the same manner that it supports the use of IEC Function Blocks;supports the assignment of control entities to specific PCO platforms;the importation of instruments lists to generate, and PCOs.

5.3.3 The Graphic Editor

The Graphic Editor support all of the human interface (HI) functionalityand graphics typical of this type of editor.

5.3.4 Application Configuration

Applications can only be assigned to native web servers.

5.3.4.1 Historian Object Editor

A historian object when found in a CO is a representation of a portionof the full historian configuration, e.g., a slice of the historian. Thehistorian object consists of the name of the historian to receive thedata and a list of PCO attributes. Each attribute is associated withcertain critical information related to the historian, e.g., changedeltas, sample rates, reduction operations, archive characteristics,etc. Starting the historian editor resulting in showing the fullconfiguration of the historian(s) to which this object is assigned.

5.3.4.1.1 Historian Data Definition Object Editor

One historian object exists for each historian in the system. Theseobjects are created automatically if a historian data definition objectis created and assigned to a historian. The data in this object controlsthe general function of the historian, e.g., where it runs in thesystem, what its archive policy is, what its data reduction policy is,etc.

5.4 Process Control 5.4.1 Definition of the Process Control Domain

The process control domain is usually divided into three primary controlstyles: (i) analog control (continuous), (ii) logic control (ladderlogic), and (iii) sequential control (supervisory operation of logic andanalog control structures). In addition, every process control systemmust address batch (or recipe based) manufacturing with the relatedtopics of lot tracking and validation.

The illustrated control system 10 views these styles as particularvisualizations of the process control functionality. This means thatthese three types of control do not exist as objects. Rather, thecontrol system receives a class definition of a process control object(PCO) which it instantiates and executes. It is the responsibility ofthe control editor to create the correct representation of the controlstructure while also representing that control structure in one of theindustry standard formats, i.e., ladder-logic, function blocks, orstructured text, or PCOs directly

Sequential Function Charts are a meta-language used to control theexecution of the other three languages. In the illustrated embodiment,it serves as a wrapper class for the other classes. The source code fora control scheme and the critical values for its PCO attributes, i.e.,its checkpoint file, are held in the non-volatile memory of the Nativedevice.

5.4.2 Process Control Objects 5.4.2.1 PCO Attributes

The fundamental control object is a PCO attribute. As noted above, theseare provided in two types: variables and parameters. An example of avariable attribute is a measurement in a PID block. In the illustratedsystem, a PCO attribute is an object in its own right and it containscertain vital information when it is retrieved. This information is“atomic”, i.e., all information is obtained with an attribute, not justits “value”. The minimal set of information from a PCO variableattribute is value, data type, quality information time tag inmilliseconds, and alarm status. It is this object that is transferredfrom one PCO to another to implement the transfer of information neededin an actual control scheme.

Parameter attributes bundle less information than a variable attribute.The typical example of a parameter attribute is the proportional band ofa PID block. In the illustrated control system 10, this attribute hasless supporting information than a variable attribute, e.g., it wouldnot have an engineering unit range.

5.4.2.2 PCO Blocks

PCO attributes and methods to operate on those attributes are combinedinto PCO Blocks. These blocks are analogous to the control blocks inother systems, e.g., I/A Series FoxBlocks, IEC 1131-3 Function Blocks,and Foxboro Microspec Blocks. However, because they are implemented inJava, they can be executed on any microprocessor running any OS thatsupports a JVM. In addition, they are designed to occupy only the amountof RAM required for the selected options and to be on-line replaceable.

PCO blocks capture and encapsulate knowledge of regulatory controlalgorithms needed to by continuous processes. The PCO user block can beused to integrate particular user-defined control algorithms into a PCOcontrol scheme. It is the PCO user block that is used to implementcontrol strategies that are defined using one of the IEC 1131-3 controllanguages.

5.4.2.3 PCO Composites

PCO Composites are implementations of a control strategy. They consistof PCO blocks and other PCO composites linked in such a manner as toprovide the control mechanisms needed for a particular process. It isthe PCO composite that captures application level control expertise,e.g., complex control structures for major pieces of equipment or eventhe simpler idioms of cascade control.

5.4.3 PCO Execution Environment

The PCO execution environment is the software in a native control devicethat supports the execution of PCOs. This software includes the JVM andany other required code, such as a class loader that loads stand-aloneapplications for each composite, a class loader that loads an applet foreach composite, a block processor that loads Java byte codes for acomposite and executes each composite in turn, and a block processorthat loads Java byte codes for PCO Blocks and executes each blocks inturn.

5.5 Communications 5.5.1 Requirements 5.5.1.1 Communication ModelDefinition

Several types of communication are provided in the illustrated controlsystem 10. These types include data transfer, message transfer betweenapplication programs, object movement (downloads), class file (code)transfers, and events (unsolicited messages).

The communications mechanism is redundant, i.e., the failure of onestation in the system does not prevent communication (new orestablished) between any two other stations. It also minimizes theimpact on uninvolved stations when the service is used by its clients,e.g., a message is not sent to a network segment if it is not going tobe used there. The communications mechanism, moreover, provides anencapsulated implementation that can be replaced “under the hood” as newtechnologies become available. Also, it allows the illustrated controlsystem 10 to be configured for the appropriate communication resources,e.g., the number of outbound connections. Moreover, it providesperformance statistics, e.g., high, low, average transfer times betweentwo stations, bytes per seconds between two stations, etc., for viewingin the system monitor. Still further, it automatically reconnects to anobject if it is relocated on or removed from/restored to the network.

Data transfer in the illustrated control system 10 is provided by amechanism that permits clients to subscribe to updates in a object. Italso provides a mechanism for one-shot get/set access to an object. Aclient of the data transfer facility supplies the control system with a(i) number of objects that it needs, (ii) conditions under which itwants updates: change delta, maximum time between updates, or both,(iii) be capable of retrieving the values all at once (a snapshot), and(iv) be capable of retrieving the values as series of changes with theoption to block, for a user specified amount of time, while waiting fora change. Client publication (write lists) are not supported in theillustrated embodiment. Target devices subscribe to the data in thesource device.

With respect to client one-shots (get), the client of the data transferfacility supplies the system with a number of objects that it needs andretrieve the values all at once (a snapshot). Conversely, with respectto client one-shots (set), the client supplies the system with a numberof objects that it wishes to change, and set any part of the object ifit has access. The parts referred to are the supporting information in aPCO attribute as well as the value part.

5.5.1.1.1 Message Transfer 5.5.1.1.1.1 General

While the message transfer mechanism is a general case of the datatransfer mechanism, its requirements are given separately. The client ofthe message transfer facility must support private conversations betweenapplications using a reliable communications mechanism and support bysubscription publication of information from one server to many clients.

5.5.1.1.1.2 Private Conversations

The private conversation mode allows applications to find each other bytheir application name: the client application is not required to knowthe station name or IP address of the server application. It also allowapplications to send records (messages) of arbitrary size: the privateconversation mode guarantees that the message boundary is recognized andthat order is preserved. Moreover, it allows both the sending andreceiving process to determine if the connection is lost. Still further,it supports transaction based message transfer, i.e., the sender doesnot get an acknowledgement until the receiver says that the message issafely stored.

5.5.1.1.1.3 Subscriptions

The subscription facility supports senders and listeners. A sender is aprocess that has data that may be of interest to one or more listeners.The subscription mode supports this type of operation by allowing a“sending” process to register that it will produce messages of aparticular type, allowing a “listening” process to register to receiveall messages of a particular type, supporting transaction basedsubscription if the client so requests (this request would have noimpact on the sender), and supporting transaction based publishing by aserver if the server requests it (this request would have no impact onthe receiver). If no listeners are registered, the subscription facilitydefines how the message is handled.

5.5.1.2 Security

The native communications system is linked to the native security systemto ensure that unauthorized users are unable to access objects. Theillustrated control system 10 does not arbitrate between users of aresource. The prevention of multiple access to an object is theresponsibility of the object. The breaking of an application securedlink by an operator is not a function of the illustrated control system10.

5.5.1.3 Object Location Services

Object are located by name. To this end, the object location servicesupports the location of named objects; supports hierarchical objectnames; allows rule based specification of the name delimiting character;locates an object based on a “longest fit” because (a) not all parts ofan object name are globally known and (b) not all parts of an object arein the same physical location; supports the implementation of namingscopes, i.e., limiting the visibility of names; supports the use of aname search path so that relative names can be located; is redundant;supports locating many types of objects, e.g., server processes, PCOattributes, and application programs; and supports the addition ofrelated information about the object in the name directory, e.g., objecttype, short-cut information to be used by the process that owns theobject, object type/implemented interface, and information. With respectto the last item, the object location services permit a client torequest the name of a service that supports a specific interface. Thisallows new interfaces to be added to a service without breaking an oldone.

5.5.1.4 Networks

The illustrated control system operates over any IP based network 48. Byway of non-limiting example, the illustrated control system 10 operatesover wide area networks supplied by the customer, installed plant LANssupplied by the customer, dedicated LANs supplied either by the customeror the vendor, redundant LANs supplied by the vendor. This operation istransparent to all applications using the system 10. While it isrecognized that performance are degraded over low bandwidth (phonelines) and high latency (geosynchronous satellites) networks, the system10 optimizes as best it can to minimize the impact of different networktypes. In short, the illustrated control system 10 does not assume thatit “owns” the network.

5.5.1.5 Quality of Service 5.5.1.5.1 Performance

Assume that the illustrated control system 10 is operating in support ofa PCO in a dedicated control station (not a transmitter) or in a PC, itsupports at least 10,000 object value gets/sets per second if the objectis in the local station; supports at least 100 get/set per secondrequests from a client if the object is in a remote station; supports atleast 50 get/set requests per second made to a server from a remoteclient; is able to locate 3000 objects per second; is able to detect acommunication failure in no more than 1000 milliseconds; ensures thatthe time to move data from a server station to a client station (APIcall to API call) is less than 100 milliseconds in a normally configurednetwork; allows a server station to move 6000 values out of its boxevery second; allows a client station to accept at least 2000 valuesevery second; allows an unlimited (but, configured) number of names tobe defined in the system; and supports the registration of 50,000globally known names without requiring a reconfiguration. All serverstations are able to support at least 30 client stations for continuousdata feed without requiring a reconfiguration. All client stationssupport at least 30 server stations for continuous data feeds withoutrequiring a reconfiguration.

5.5.1.6 APIs

Within the illustrated control system 10 environment an API are providedfor all of the above services. This API are delivered as a Java Bean sothat the underlying communications mechanism may be replaced withoutbreaking all of the applications that use the service.

5.5.1.7 Maintenance and Upgrades of Messaging Services

The illustrated control system 10 defines and enforces a mechanism forsupporting inter-operability of messages from stations at differentversions. A mechanism like interface inheritance is provided, i.e., amessage carries in it enough “type” information that the receivingapplication knows how to “decode” the message even if the receivingapplication is at a lower level. This adds fields to messages ifnecessary, but not remove/replace old fields.

5.5.1.8 Integration of non-Native Based Systems

The illustrated control system 10 supports integration of non-Javaapplications using appropriate technologies, e.g., CORBA,COM/DCOM/ActiveX, and emulation of APIs. Physical gateways arepermitted, but these gateways provide only a minimal amount ofconfiguration.

5.5.1.9 Object Location Service Implementation 5.5.1.9.1 The All JavaApproach 5.5.1.9.1.1 Description

JINI and JavaSpaces technologies permit object location within theillustrated system. JINI technology allows native devices to registernames in a globally available database. JINI clients can find thisdatabase and perform searches against it. JavaSpaces allow a device toregister important information in a globally available bulletin board.JavaSpaces provide four simple services: posting, removal, query byexample, and notification. The notification feature informs prospectiveusers of a class of objects when such objects are added and removed fromthe JavaSpace. A JavaSpace handles services like system monitoring.

5.5.1.9.2 The Enhanced Object Manager Approach 5.5.1.9.2.1 Description

As an alternative, an enhanced object manager (EOM) approach to addresslocation and connection of data clients and servers can be utilized asfollows:

-   -   1) A LDAP compliant service are created and used to store        pathnames and related information, e.g., IP addresses, Port        Numbers, internal indexes, etc.    -   2) The EOM API provides get/set and read/write support similar        to that provided by the OM today.    -   3) When provided a name, the EOM looks in the local copy of the        LDAP database.    -   4) If the name is found and the data is local, the request is        passed to the correct data provider (the EOM, the CIO database,        or the AOS database) who returns the value and other data. The        EOM handles sending updates on change driven data.    -   5) If the name is found and not local, the EOM sends the request        to the remote EOM which then makes a local query. The EOM        handles sending updates on change driven data.    -   6) If the name is not found locally, the location request is        passed to the master LDAP database. If it is found there, the        address information is passed back to the local LDAP database        (which is updated) and steps 4) and 5) are repeated.    -   7) If the name is not found remotely, the request is posted for        a period of time. If it is resolved in that period, the        requesting station is notified. If it is not resolved, the        master LDAP database drops the name and notifies the requesting        station.

5.6 Critical Applications 5.6.1 Time Synchronization

SNTP (Simple Network Time Protocol) is used to keep operator stationsand similar non-process data producers in sync. This protocol is asaccurate as 1 ms in a carefully controlled environment, but 50 ms ismore common on shared networks. Controllers requiring high accuracy areplaced on tightly controlled networks or equipped with an interrupt usedto coordinate time updates. In either case, a master timekeeper tied toa well known reliable data source—GPS clock or broadcasted time from thenational atomic clocks. This master time keeper generates the interruptand SNTP. It is built with a highly reliable internal clock so that lossof time feed does not result in significant drift within the Mean Timeto Repair (MTTR).

5.6.2 Alarm and Message Management

Alarm and message manage requires that all process alarming to be basedon the top-level composite's attributes; that acknowledgments be handledat the composite level; that PCOs, system monitors, and the native humaninterface a reliable message protocol to send the message to a messagemanagement system (MMS); that the MMS is used by end-users to view thecurrent alarm state and the alarm history; and that the MMS use theplant historian to permanently store and archive messages.

To meet the control market's requirement for a message managementsystem, the illustrated control system 10 provides a message managementsupport service (MMSS) in the native devices that are used to delivermessages to a Message Manager. The service operates as follows.

When a client of the MMSS connects to the MMSS server, the MMSS serversend any messages in its internal alarm queue that are older than thetime of the connection to the client; transmits the alarm state at thetime of the connection to the client, and transmit any new messagessubsequent to the connection. If the connection to the MMSS clientfails, there is no impact on the operation of the control station or thecontrol network; minor delays associated with detecting the loss ofconnection are generally viewed as acceptable. The MMSS support at leasttwo (2) and, preferably, four simultaneous clients.

The alarm state of a PCO attribute is defined to include block attributeidentification (full PATH attribute name, at least); the bad I/O statusof the block for I/O attributes; an indication of the alarm status foreach alarm type defined for the attribute; the priority, criticality,and acknowledgment status of the attribute; the on/off status of theattribute, i.e., is it updating; the status of the alarm inhibit andalarm disable or alarm option parameters, and the time tag of each alarmevent stored within the block, e.g., the into alarm time, theacknowledged time, and the return to normal time. This information isrecovered from all currently active alarms.

5.6.2.1 Configuration 5.6.2.1.1 Process Alarms

When a composite is configured, the application engineer specifies whichattributes of the PCOs within the composite are to be annunciated. Whena composite is placed on line, it notifies the object location servicethat it exists. A message management service are notified of the newcomposite and arrange for notification from the device.

5.6.2.1.2 System Alarms and Messages

No user configuration is required to get these alarms into the MMS. Thesources of such messages arranges for the appropriate notification.

5.6.2.1.3 Native Operator Actions

No user configuration is required to get these alarms into the MMS. Thesources of such messages arranges for the appropriate notification.

5.6.2.2 Native Message Management Service

The MMS are centralized and redundant. It provides a complete alarmstate for the plant at any time including startup. It retains a messagehistory for as long as configured through the use of the planthistorian. Users view the alarms through to the Alarm Manager.

6 Native Hardware SubSystems 6.1 Field Devices 6.1.1 Overview

The native field devices are coupled to the network 48 via an IPnetwork, preferably, Ethernet and, still more preferably, poweredEthernet. Powered Ethernet delivers the power, along with conventionalEthernet data. To this end, the native field devices use one of twowiring schemes, with each scheme supplying power to the field device:(a) standard four wire 10Base-T wiring, or (b) industry standardtwo-wires used for 4-20 ma based transmitters. The devices also providea single Ethernet interface (or redundancy, where desired in the cablingor the field device); and connect to a non-redundant powered hub withthe following features: (a) non-redundant connections to the IFDs; and(b) support for redundant connection to a plant-wide network. Whereused, the powered Ethernet implementation leaves the physical andlogical Ethernet interfaces in place. This means that except for addinga new wiring type, the physical layer, the data link layer, the use ofCSMA/CD, and 10Base-T connectors are preserved.

The illustrated embodiment utilizes powered Ethernet hubs to providecommunications and power to its intelligent field devices. These IFDsmay be transmitters, actuators, Networked I/O, or PCO platforms. Thepowered hubs are preferably, stackable, DIN rail-mountable, supportconnection to a redundant network, and support both 10 Mbps and 100 MbpsEthernet.

A further understanding of the operation of the powered Ethernet networkand of the circuitry used within the native field and control devices todraw power therefrom may be attained by reference to U.S. patentapplication Ser. No. 09/444,827, filed Nov. 22, 1999, entitled POWEREDETHERNET FOR INSTRUMENTATION AND CONTROL (now issued as U.S. Pat. No.6,640,308), and by reference to the corresponding PCT Patent ApplicationUS00/10013, filed Apr. 14, 2000, the teachings of both of which areincorporated herein by reference.

On the software side, specific implementations of the native fielddevices support web based configuration, as described above. The supportis supplied by including an embedded web server with a selection ofpages used for configuration and maintenance.

6.1.2 Transmitters

Intelligent transmitters use the IEEE 1451 standard to communicate totheir sensor(s). This facilitates use of the same module in many typesof transmitters from potentially many vendors and allows the transmitterto support up to 255, perhaps externally mounted, sensing devices.

6.1.3 Positioners

The native intelligent positioners also support a powered Ethernetinterface like the one used by the native intelligent transmitters. FIG.6 shows a preferred native intelligent positioner implementation. Theapproach standardize interfaces and use a PCO to control the positioneras evident in the drawing.

6.2 Summary of Hardware/Software Features by Station Type

A summary of the features of native control devices follows. Blank cellsindicate that the feature is not present in the indicated device.

Features PC based Operator Native PC Based Solid-state SS DHCP SSbulletin Xmitter Positioner Controller Integrator Consoles WorkstationWeb Server Web Server Server board Low power, high Yes Yes Yesperformance CPU Top performance Yes Yes Yes Yes Yes Yes CPU RAM Yes YesYes Yes Yes Yes Yes Yes Yes Yes ROM Yes Yes Yes Yes Yes Yes Yes Yes YesYes Flash Yes Yes Yes Yes Yes Yes Yes Yes Yes Sensor I/F Yes Yes (IEEE1451) Powered Ethernet Yes Yes (2 wire) Serial I/F (RS- Yes Yes Yes232/485/422/423) Ethernet Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes(10Base-T) Wireless Ethernet Yes Yes the TCP/IP suite Yes Yes Yes YesYes Yes Yes Yes Yes Yes DHCP Server Yes Yes Yes Yes Full OS Yes Yes YesYes Yes Yes Yes Yes Yes Yes Java Virtual Yes Yes Yes Yes Yes Yes Yes YesYes Yes Machine Web Server Yes Yes Yes Yes Yes Yes Yes Yes Yes DeviceYes Yes Yes Yes Yes Yes Configurator Annunciator Yes Yes KeyboardTouchscreen Yes Yes Mouse/Trackball Yes Yes Display Yes Yes Yes Yes Harddrive Yes Yes Solid State Bulk Yes Yes Storage System Monitor Yes YesProcess Control Yes Yes Yes Yes Yes Yes Yes Yes Objects (PCOs) SystemYes Yes Yes Yes Yes Yes Yes Yes Yes Yes Management Objects Omnibus YesYes Yes Yes Yes Yes Yes Yes Messaging Services Profibus PA Opt. Opt. YesSupport Profibus DP Opt. Opt. Yes Support HART Support Opt. Opt. YesFoxComm Opt. Opt. Yes Support Fieldbus HSE Opt. Opt. Yes SupportFieldbus H1 Opt. Opt. Yes Support DeviceNet Opt. Opt. Yes LONworks Opt.Opt. Yes Modbus Yes Modbus+ Yes ABDH Yes I/A Series Yes Nodebus I/ASeries Opt. Opt. Yes Fieldbus (FoxComm) Application Yes DevelopmentEnvironment Historian Yes Time Yes Yes Synchronization PIMS Yes MessageYes Management

Described above are apparatus and methods that achieve the goals of theinvention. It will be appreciated that the embodiments described hereinare examples and that other embodiment incorporating changes theretoalso fall within the scope of invention. Thus, by way of example, itwill be appreciated that the invention can be implemented using avirtual machine environment other than JVM and using bytecode other thanJava bytecode. By way of further example, it will be appreciated thatthe apparatus and methods taught herein can be applied to a range ofcontrol application, in addition to process control.

1-228. (canceled)
 229. A control system, comprising: A. a plurality ofcontrol system components in communications coupling via an IP network,B. at least a first control system component providing one or moreservices via the IP network to at least a second control systemcomponent, C. wherein the second component comprises any of anintelligent transmitter, intelligent actuator, and an intelligentpositioner.
 230. The control system of claim 229, wherein the secondcomponent comprises a processor.
 231. The control system of claim 229,wherein the IP network comprises any of an LAN, WAN, and the Internet.232. The control system of claim 229, wherein the first componentcomprises any of an enabler and a bulletin board server.
 233. Thecontrol system of claim 229, wherein the first component comprises anyof a DHCP server, a JINI server, and a Javaspaces server.
 234. Thecontrol system of claim 229, wherein the one or more services enable thesecond component to locate an object in the control system, the objectbeing associated with a third control system component.
 235. The controlsystem according to claim 234, wherein the third component comprises anyof a control device, a field device, a controller, a workstation, aplant server, an enterprise server, and a system monitor.
 236. Thecontrol system of claim 229, wherein the one or more services includeenabling the second component to any of: (i) register a name specifiedby the second component with the service, (ii) search for namesspecified by the second component on the service, (iii) post eventsspecified by the second component, (iv) remove posted events specifiedby the second component, (v) querying the service as specified by thesecond component, (vi) be notified of control system events specified bythe second component.
 237. The control system of claim 229, wherein theone or more services are accessible via a Java Bean delivered over theIP network.
 238. The control system of claim 229, wherein the secondcomponent is capable of executing a control algorithm that at least oneof (i) maintains the control system at a desired level and (ii) drivesit to that level.
 239. The control system of claim 229, wherein thesecond component comprises a web server for facilitating any ofconfiguration, monitoring, and/or maintenance of the second component oranother one of the plurality of control system components.
 240. Thecontrol system of claim 229, wherein the second component comprises aweb server that any of (i) collects process data from one or morecontrol system components, (ii) generates source for operator displays,(iii) provides access to the control system, and (iv) hosts anapplications development environment.
 241. A control system, comprising:A. a plurality of control system components in communications couplingvia an IP network, B. at least a first control system componentproviding one or more services via the IP network to at least a secondcontrol system component, the one or more services includingestablishing communications between the second component and a thirdcontrol system component, C. wherein the second component comprises anyof an intelligent transmitter, intelligent actuator, and an intelligentpositioner.
 242. The control system of claim 241, wherein the one ormore services includes facilitating the transfer of any of data,messages, and objects between the second and third control systemcomponents.
 243. The control system of claim 241, wherein the one ormore services include a publication/subscription service that enablesthe second component to publish any of data, messages, and objects overthe IP network and/or to subscribe to any of data, messages, andobjects, published by a third control system component over the IPnetwork.
 244. The control system of claim 241, wherein the one or moreservices comprises notifying the second component of an event related toa third control system component.
 245. The control system of claim 244,wherein the wherein the event comprises an update to an object.
 246. Thecontrol system of claim 244, wherein the event comprises an unsolicitedmessage from the third component.
 247. The control system according toclaim 241 wherein the third component comprises any of a control device,a field device, a controller, a workstation, a plant server, anenterprise server, and a system monitor.
 248. The control system ofclaim 241, wherein the one or more services are accessible via any of:(i) a Java Bean delivered over the IP network, (ii) JINI, (iii)JavaSpaces.
 249. A control system, comprising: A. a plurality of controlsystem components in communications coupling via an IP network, B. atleast a first control system component providing one or more servicesvia the IP network to at least a second control system component, theone or more services enabling the second component to get and/or set avalue associated with a third one of the control system components, andC. wherein the second component comprises any of an intelligenttransmitter, intelligent actuator, and an intelligent positioner. 250.The control system of claim 249, wherein the value associated with thethird component is included in an object.
 251. The control system ofclaim 249, wherein the third component comprises any of a controldevice, a field device, a controller, a workstation, a plant server, anenterprise server, and a system monitor.
 252. The control system ofclaim 249, wherein the one or more services includes notifying thesecond component of an event related to the third component.
 253. Thecontrol system of claim 249, wherein the second component is capable ofexecuting a control algorithm that at least one of (i) maintains thecontrol system at a desired level and (ii) drives it to that level. 254.The control system of claim 249, wherein the one or more services areaccessible via any of: (i) a Java Bean delivered over the IP network,(ii) JINI, (iii) JavaSpaces.
 255. A control system, comprising: A. aplurality of control system components in communications coupling via anIP network, B. at least a first control system component providing oneor more services via the IP network to at least a second control systemcomponent, the one or more services enabling any of the second componentand a third control system component to register one or more of theircharacteristics therewith, C. wherein the second component comprises anyof an intelligent transmitter, intelligent actuator, and an intelligentpositioner.
 256. The control system of claim 255, wherein the one ormore services includes enabling the second device to register one ormore of its characteristics and, thereby, to enter into one or morerelationships with other services in the control system.
 257. Thecontrol system of claim 255, wherein the one or more services include abulletin board service that provides any of a name service, lookupservice, and a query-by-example service.
 258. The control system ofclaim 255, wherein the one or more services include enabling the secondcomponent to any of: (i) register a name specified by the secondcomponent with the service, (ii) search for names specified by thesecond component on the service, (iii) post events specified by thesecond component, (iv) remove posted events specified by the secondcomponent, (v) querying the service as specified by the secondcomponent, (vi) be notified of control system events specified by thesecond component.
 259. The control system of claim 258, wherein the oneor more services are provided at least in part by any of a Javaspaceservice, a JINI service and a DHCP service.
 260. The control system ofclaim 255, wherein the one or more services include enabling the secondcomponent to locate an object in the control system.
 261. The controlsystem of claim 255, wherein the one or more services includes any of(i) a sending service that enables the second component to registertherewith that the second component will produce messages of one or moretypes via the IP network; and (ii) a listening service that enables thesecond component to register therewith to receive one or more messagesof one or more types via the IP network.
 262. The control system ofclaim 255 wherein the third component comprises any of a control device,a field device, a controller, a workstation, a plant server, anenterprise server, and a system monitor.
 263. A control system,comprising: A. a plurality of control system components incommunications coupling via an IP network, B. at least a first controlsystem component providing one or more services via the IP network to atleast a second control system component, the one or more servicescomprising at least one of (i) recording a state of operation of thesecond component, and (ii) enabling a system monitor to access therecorded state of the second component, and C. wherein the secondcomponent comprises any of an intelligent transmitter, intelligentactuator, and an intelligent positioner.
 264. The control system ofclaim 263, wherein the recorded state of operation includes diagnosticinformation.
 265. The control system of claim 263, wherein the secondcomponent is capable of executing a control algorithm that at least oneof (i) maintains the control system at a desired level and (ii) drivesit to that level.
 266. The control system of claim 263, wherein thefirst component comprises any of an enabler and a bulletin board server.267. A control system, comprising: A. a plurality of control systemcomponents in communications coupling via an IP network, B. at least afirst control system component providing one or more services via the IPnetwork to at least a second control system component, C. an interfacecommunicatively coupled to the IP network and to one or more of theservices, the interface facilitating invocation of the service by thesecond component, D. wherein the second component comprises any of anintelligent transmitter, intelligent actuator, and an intelligentpositioner.
 268. The control system of claim 267, wherein the interfacecomprises an applications program interface (API).
 269. The controlsystem of claim 268, wherein the API is downloaded to the secondcomponent over the network.
 270. The control system of claim 269,wherein the API is downloaded via a Java Bean.
 270. The control systemof claim 267, wherein the interface comprises at least one of a JavaAPI, JavaSpaces API, and JINI API.
 271. The control system of claim 267,wherein the second component is capable of executing a control algorithmthat at least one of (i) maintains the control system at a desired leveland (ii) drives it to that level.
 272. A control system, comprising: A.a plurality of control system components in communications coupling viaan IP network, B. at least a first control system component providingone or more services via the IP network to at least a second controlsystem component, C. wherein the second component is capable ofimplementing any of a continuous, logic, or batch process controlstrategy, D. wherein the second component comprises any of anintelligent transmitter, intelligent actuator, and an intelligentpositioner.
 273. The control system of claim 272, wherein the one ormore services including establishing communications between the secondcomponent and a third one of the control system components.
 274. Thecontrol system according to claim 273, wherein the third componentcomprises any of a control device, a field device, a controller, aworkstation, a plant server, an enterprise server, and a system monitor.275. The control system of claim 272, wherein the one or more servicescomprises notifying the second component of an event related to a thirdone of the control system components.
 276. The control system of claim272, wherein the one or more services including enabling the secondcomponent to any of: (i) register a name specified by the secondcomponent with the service, (ii) search for names specified by thesecond component on the service, (iii) post events specified by thesecond component, (iv) remove posted events specified by the secondcomponent, (v) querying the service as specified by the secondcomponent, (vi) be notified of control system events specified by thesecond component.
 277. The control system of claim 272, wherein the oneor more services include enabling the second component to get and/or seta value associated with a third one of the control system components.278. The control system of claim 277, wherein the wherein the eventcomprises an update to an object.
 279. The control system of claim 277,wherein the event comprises an unsolicited message from the thirdcomponent.
 280. The control system of claim 272, wherein the one or moreservices includes any of (i) recording a state of operation of thesecond component, and (ii) enabling a system monitor to access therecorded state of the second component.